<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>Replication Manager methods</title>
    <link rel="stylesheet" href="gettingStarted.css" type="text/css" />
    <meta name="generator" content="DocBook XSL Stylesheets V1.73.2" />
    <link rel="start" href="index.html" title="Berkeley DB Programmer's Reference Guide" />
    <link rel="up" href="rep.html" title="Chapter 13.  Berkeley DB Replication" />
    <link rel="prev" href="rep_app.html" title="Building replicated applications" />
    <link rel="next" href="rep_base_meth.html" title="Base API methods" />
  </head>
  <body>
    <div xmlns="" class="navheader">
      <div class="libver">
        <p>Library Version 12.1.6.2</p>
      </div>
      <table width="100%" summary="Navigation header">
        <tr>
          <th colspan="3" align="center">Replication Manager methods</th>
        </tr>
        <tr>
          <td width="20%" align="left"><a accesskey="p" href="rep_app.html">Prev</a> </td>
          <th width="60%" align="center">Chapter 13.  Berkeley DB Replication </th>
          <td width="20%" align="right"> <a accesskey="n" href="rep_base_meth.html">Next</a></td>
        </tr>
      </table>
      <hr />
    </div>
    <div class="sect1" lang="en" xml:lang="en">
      <div class="titlepage">
        <div>
          <div>
            <h2 class="title" style="clear: both"><a id="rep_mgr_meth"></a>Replication Manager methods</h2>
          </div>
        </div>
      </div>
      <p>
        Applications which use the Replication Manager support
        generally call the following Berkeley DB methods. The general
        pattern is to call various methods to configure Replication
        Manager, and then start it by calling <a href="../api_reference/C/repmgrstart.html" class="olink">DB_ENV-&gt;repmgr_start()</a>. Once this
        initialization is complete, the application rarely needs to
        call any of these methods. (A prime example of an exception to
        this rule would be the <a href="../api_reference/C/repsync.html" class="olink">DB_ENV-&gt;rep_sync()</a> method, if the application is
        <a class="xref" href="rep_mastersync.html#rep_delay_sync" title="Delaying client synchronization">Delaying client synchronization</a>.)
    </p>
      <div class="variablelist">
        <dl>
          <dt>
            <span class="term">
              <a href="../api_reference/C/db_site.html" class="olink">DB_SITE</a>
            </span>
          </dt>
          <dd>
            <p>
                    The <a href="../api_reference/C/db_site.html" class="olink">DB_SITE</a> handle is used to configure a site
                    that belongs to the replication group. You can
                    obtain a <a href="../api_reference/C/db_site.html" class="olink">DB_SITE</a> handle by calling the
                    <a href="../api_reference/C/repmgr_site.html" class="olink">DB_ENV-&gt;repmgr_site()</a> method. When you do this, you
                    provide the TCP/IP host name and port that the
                    replication site uses for incoming connections. 
                </p>
            <p> 
                    Once you have the <a href="../api_reference/C/db_site.html" class="olink">DB_SITE</a> handle, you use the
                    <a href="../api_reference/C/dbsite_set_config.html" class="olink">DB_SITE-&gt;set_config()</a> method to configure the
                    handle. One of the things you can configure about
                    the handle is whether it is the local site (using
                    the <code class="literal">DB_LOCAL_SITE</code> parameter).
                    You must configure one and only one <a href="../api_reference/C/db_site.html" class="olink">DB_SITE</a>
                    handle to be a local site before you start
                    replication.
                </p>
            <p> 
                    You can also optionally configure <a href="../api_reference/C/db_site.html" class="olink">DB_SITE</a>
                    handles for remote sites to help Replication
                    Manager start up more efficiently. Note that it is
                    usually not necessary for each site in the
                    replication group initially to know about all
                    other sites in the group. Sites can discover each
                    other dynamically, as described in <a class="xref" href="rep_newsite.html" title="Connecting to a new site">Connecting to a new site</a>. 
                </p>
            <p> 
                    Once you have configured your <a href="../api_reference/C/db_site.html" class="olink">DB_SITE</a> handles,
                    you start replication using <a href="../api_reference/C/repmgrstart.html" class="olink">DB_ENV-&gt;repmgr_start()</a>. 
                </p>
            <p> 
                    When you are shutting down your application,
                    you must use the <a href="../api_reference/C/dbsite_close.html" class="olink">DB_SITE-&gt;close()</a> method to close
                    all your open <a href="../api_reference/C/db_site.html" class="olink">DB_SITE</a> handles before you close
                    your environment handles. 
                </p>
          </dd>
          <dt>
            <span class="term">
              <a href="../api_reference/C/repmgrset_ack_policy.html" class="olink">DB_ENV-&gt;repmgr_set_ack_policy()</a>
            </span>
          </dt>
          <dd>
            <p> 
                    The <a href="../api_reference/C/repmgrset_ack_policy.html" class="olink">DB_ENV-&gt;repmgr_set_ack_policy()</a> method configures the
                    acknowledgement policy to be used in the
                    replication group, in other words, the behavior of
                    the master with respect to acknowledgements for
                    "permanent" messages, which implements the
                    application's requirements for <a class="xref" href="rep_trans.html" title="Transactional guarantees">Transactional guarantees</a>. 
                    The current implementation requires all sites
                    in the replication group to configure the same
                    acknowledgement policy.
                </p>
          </dd>
          <dt>
            <span class="term">
              <a href="../api_reference/C/reppriority.html" class="olink">DB_ENV-&gt;rep_set_priority()</a>
            </span>
          </dt>
          <dd>
            <p> 
                    The <a href="../api_reference/C/reppriority.html" class="olink">DB_ENV-&gt;rep_set_priority()</a> method configures the local
                    site's priority for the purpose of elections.
                </p>
          </dd>
          <dt>
            <span class="term">
              <a href="../api_reference/C/repset_timeout.html" class="olink">DB_ENV-&gt;rep_set_timeout()</a>
            </span>
          </dt>
          <dd>
            <p> 
                    This method optionally configures various
                    timeout values. Otherwise default timeout values
                    as specified in <a href="../api_reference/C/repset_timeout.html" class="olink">DB_ENV-&gt;rep_set_timeout()</a> are used. In
                    particular, Replication Manager client sites can
                    be configured to monitor the health of the TCP/IP
                    connection to the master site using heartbeat
                    messages. If the client receives no messages from
                    the master for a certain amount of time, it
                    considers the connection to be broken, and calls
                    for an election to choose a new master. Heartbeat
                    messages also help clients request missing master
                    changes in the absence of master activity. 
                </p>
          </dd>
          <dt>
            <span class="term">
              <a href="../api_reference/C/envevent_notify.html" class="olink">DB_ENV-&gt;set_event_notify()</a>
            </span>
          </dt>
          <dd>
            <p>
                    Once configured and started, Replication
                    Manager does virtually all of its work in the
                    background, usually without the need for any
                    direct communication with the application.
                    However, occasionally events occur which the
                    application may be interested in knowing about.
                    The application can request notification of these
                    events by calling the <a href="../api_reference/C/envevent_notify.html" class="olink">DB_ENV-&gt;set_event_notify()</a> method.
                </p>
          </dd>
          <dt>
            <span class="term">
              <a href="../api_reference/C/repmgrstart.html" class="olink">DB_ENV-&gt;repmgr_start()</a>
            </span>
          </dt>
          <dd>
            <p> 
                    The <a href="../api_reference/C/repmgrstart.html" class="olink">DB_ENV-&gt;repmgr_start()</a> method starts the replication
                    system. It opens the listening TCP/IP socket and
                    creates all the background processing threads that
                    will be needed. 
                </p>
          </dd>
        </dl>
      </div>
      <p>
        In addition to the methods previously described,
        Replication Manager applications may also call the following
        methods, as needed: <a href="../api_reference/C/repconfig.html" class="olink">DB_ENV-&gt;rep_set_config()</a>, <a href="../api_reference/C/repset_limit.html" class="olink">DB_ENV-&gt;rep_set_limit()</a>, <a href="../api_reference/C/repset_request.html" class="olink">DB_ENV-&gt;rep_set_request()</a>,
        <a href="../api_reference/C/repsync.html" class="olink">DB_ENV-&gt;rep_sync()</a> and <a href="../api_reference/C/repstat.html" class="olink">DB_ENV-&gt;rep_stat()</a>. 
    </p>
      <p> 
        If a Replication Manager replication group contains only two
        sites and one particular site should be master whenever
        possible, the replication group can be configured to run in
        preferred master mode. For more information, see
        <a class="xref" href="rep_twosite.html#twosite_prefmas" title="Preferred master mode">Preferred master mode</a>.
    </p>
      <p> 
        Replication Manager applications may configure one or more
        view sites. A view is a full or partial copy of the replicated
        data that does not otherwise participate in the replication
        group. For more information, see <a class="xref" href="rep_partview.html" title="Replication views">Replication views</a>. 
    </p>
      <p>
        Finally, Replication Manager applications can also make use
        of the Replication Manager's message channels. This allows the
        various sites in the replication group to pass messages that
        are tailored to the application's requirements. For more
        information, see <a class="xref" href="comm_repsites.html#repmgr_channels" title="Using Replication Manager message channels">Using Replication Manager message channels</a>.
    </p>
    </div>
    <div class="navfooter">
      <hr />
      <table width="100%" summary="Navigation footer">
        <tr>
          <td width="40%" align="left"><a accesskey="p" href="rep_app.html">Prev</a> </td>
          <td width="20%" align="center">
            <a accesskey="u" href="rep.html">Up</a>
          </td>
          <td width="40%" align="right"> <a accesskey="n" href="rep_base_meth.html">Next</a></td>
        </tr>
        <tr>
          <td width="40%" align="left" valign="top">Building replicated applications </td>
          <td width="20%" align="center">
            <a accesskey="h" href="index.html">Home</a>
          </td>
          <td width="40%" align="right" valign="top"> Base API methods</td>
        </tr>
      </table>
    </div>
  </body>
</html>
